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[57] ABSTRACT 

A method for digitally signing a message by a tamper- 
resistant device to generate a digital signature. The method 
includes the step of hashing the message to form message 
bits; and encrypting with a private key the message bits, 
redundancy bits for the security of the signature, and audit- 
ing bits to form the digital signature for the message. The 
auditing bits provide an audit trail for the message. The 
auditing bits include one or more of the following catego- 
ries: signature -packet version bits to identify the version of 
the device generating the signature; device ID bits to iden- 
tify the token generating the digital signature; key ID bits to 
identify the private key; a packet-sequence number, which 
increments every time the device generates a signature to 
indicate the sequence of signatures generated; bits generated 
by hashing the prior signature to provide an auditing trail of 
signatures generated and a time-stamp to indicate the time 
when the signature is generated. The auditing bits may 
further include a random number, 
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DIGITAL SIGNATURE WITH AUDITING 
BITS 

BACKGROUND OF THE INVENTION 
This invention relates to cryptographic techniques, and 
more particularly to digital signatures. 

For centuries, people have been searching for ingenious 
methods to communicate privately and secretly. The meth- 
ods can simply be substituting one letter for another as Julius 
Caesar did, or as complicated as the mechanical "Enigma" 
system used by the Germans during W.W.II, which took 
hundreds of researchers years to crack. 

Many secret communication methods depend on some 
secret information, also known as a "secret code/' agreed 
upon between the sender and the receiver. The sender is also 
known as the sender token, and the receiver is also knowa 
as the receiver token; each token can be a computer, a person 
or even just an intelligent bank card. The complexity of the 
problem significantly increases when the sender and the 
receiver have never met before, such as a buyer trying to pay 
for a coat bought from a seller through the Intemet by giving 
the seller his or her charge card number. If they have not met 
before, they cannot securely settle on a secret code to 
communicate among themselves. The secret code has to be 
set through some initial communication. Unfortunately, the 
initial communication can be eavesdropped, with the secret 
code exposed. 

The public-private key encryption technique has resolved 
the above-identified problem. Based on a public-key/ 
private -key key pair, every digital message can be encrypted 
by any one of the key and decrypted by the other, with the 
public keys recorded in a public directory, which is publicly 
accessible, and the private key privately retained. Typically, 
the sender of the message would go to the public-key 
directory to look for the receiver's public key. Then the 
sender would encrypt the message with the receiver's public 
key, and convey the encrypted message to the receiver. The 
receiver, upon getting the encrypted message, decrypts the 
message with her private key. Such a public-private key 
scheme resolves the problem of maintaining the secrecy of 
a communication. However, when the receiver gets the 
message, the receiver cannot be certain that the message is 
from the sender. The receiver would like to have the equiva- 
lence of a signature on the message. 

The public-private key encryption technique can also be 
used to generate a digital signature to authenticate the 
sender. Typically, the sender would hash the message with a 
one-way hashing function that is publicly known and is an 
agreed-upon standard, such as published in the newspaper. 
Hashing a message is a computation applied to a message 
that collapses the message and transforms it to a unique 
value — no two messages have the same value. After 
hashing, the sender would digitally sign the message by 
encrypting the hashed message with her private key. Both 
the digital signature and the message will be encrypted by 
the receiver's public key, and are then sent to the receiver. 
The receiver, upon getting the information, decrypts it, and 
extracts the digital signature from it. Then the receiver gets 
the sender's public key from the public directory to decrypt 
the digital signature to get back the same message. This 
operation ensures the identity of the sender because she is 
the only person who can encrypt the message with her 
private key. One cryptosystem that allows digital signatures 
with message-recovery is RSA. There are also ElGamal 
variants, which allow signing with message recovery. 

Basic concepts on public -key encryption, digital 
signatures, and one-way hash functions are well known to 
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those with ordinary skill in the art of cryptography. Details 
can be found in many textbooks, including Applied 
Cryptography, 2nd Edition, by Bruce Schneier (John Wiley 
& Sons, 1996). 

5 The above described operations or protocols are secure as 
long as the encryption scheme is not broken. One way to 
break a protocol is to reverse-engineer the physical system 
that executes the protocol, and to then modify the protocol. 
One solution to this problem is to execute the protocol in a 

10 tamper-resistant hardware device. There are many tech- 
niques for making hardware device (such as a portable 
computer or a token) tamper-resistant, and they are well 
known in the current art. Examples of tamper-resistant 
hardware include PC-MCIA cards from National 

15 Semiconductor, Inc. and Datakey, button-memory devices 
from Dallas Semiconductor, Inc., and authenticator tokens 
by Security Dynamics, Inc. The U.S. government uses 
tamper-resistant hardware for many of its military encryp- 
tion and decryption equipment. 

Another way to break the protocol is to break the public- 
private key encryption one of the cryptographic algorithms 
(the public key algorithm, the hash function, the bulk 
encryption algorithm, etc.), which can be an almost impos- 
sible task. A public-key key-size of more than 512 bits 
would require over ten thousand MIP years to break with 
conventional computational methods and equipment. 
' However, if one is not careful, his protocols can still be 
broken. For example, in 1995, two researchers broke 
Netscape's protocol. They did not break the public -private 
key encryption, but they broke the key-generation proce- 
dure. In Netscape's protocol, two users, after they have 
secured communication through exchanging their keys, 
would transmit to each other a "secret code" or a session key 

25 based on their secured communication channel. From that 
point onwards, their communication will be encrypted using 
the session key, because an encryption using a session key 
needs much less time than an encryption method based on 
the public-private key set. Typically, a session key is based 
on a long random number. In Netscape case, a part of the 
session key is based on predictable numbers, such as the 
serial number of one of the user's computer. The two 
researchers somehow figured out the predictable part of the 
session key, broke it and exposed the secured communica- 
tion between the users. 

45 

No matter how strong a protocol is, there might be a 
possibility that it can be broken, reverse-engineered, or it 
can be stolen. A user, after being aware that her protocol has 
been broken, should be protected from the attacker or the 

50 intruder changing the protocol and convincing her to use the 
old, broken protocol as if it were a new protocol. There has 
to be some auditing trail established so that she could trace 
back aU the transactions by the hardware device (or software 
program) token to ensure her that what she has is a new 

55 protocol. This auditing trail can be based on the version of 
the protocol, the ID number of the hardware device (or 
software program)token and the ID number of the public- 
private key set. But, no matter what the trail is based on, 
there should be some way to ensure the user the security of 

60 her token. 

Similarly, the user might encounter the same problem if 
she has lost her hardware device token or if her hardware 
device token has been stolen. There must be some way to 
protect her so that unauthorized use could only last for a 
65 short duration of time, and all the unauthorized use can be 
traced back so that she is not liable for any of those 
transactions. Again, one needs to have an audit trail created 
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to trace the sequence of events or transactions using the of the signature. The auditing bits may be used to trace the 

hardware device token. This would help the user to recover identity of the source generating the message by including 

after losing her hardware device token or after her hardware one or more of the following fields: signature -packet version 

device token was broken into. bits to identify the version of the device token generating the 

There are also many applications with a need for strong S signamre; device token ID bits, which identify the device 

audit trail. The most obvious applications with such needs token generating the digital signature; or key ID bits, which 

arc for key certification and key escrow agencies. In both identify the private key encrypting the signature package, 

cases, operations such as certifying public keys, recovering The auditing bits may also be used to trace the sequence of 

private or secret keys should not be performed without events or transactions operated on by the device token 
leaving an audit trail. lO through including the packet-sequence number, which incre- 

Another application with a need for auditing is electronic «ients every time the device token generates a signature. A 

commerce. There are many financial interactions that would different signature has a different packet-sequence number; 

benefit fi-om a strong audit trail: smart-card credit or debit packet-sequence number indicates the sequence of 

cards interacting with an Automatic Teller Machine or a signatures generated by the device token. Another preferred 

point-of-sale credit-card validation machine, Intemet-based type of auditing bits that can trace the sequence of events is 

purchasing software interacting with commercial Websites, ^its representing the hashing of the immediate prior signa- 

consumers interacting with Internet-based gambling ^^^e signed by the card. This would provide an audit trail 

services, etc. In all of these circumstances there is the need where every signature includes its immediately pnor signa- 

to establish an audit trail of actions between the various t^^^- ^^^l^ ^ui^e difficult for an intruder to change such 

parties, so that an arbitrator (a judge, regulatory agency, etc.) type of audit trail because she has to change every previous 

can reconstruct events after they occurred. signature. In another preferred embodiment, the signature 

^ , . ui - u u J -4- * 1 • * package further includes a field that represents a time-stamp 

One way to establish such an auditing trad is to use a f j^'^^, . , . ..^ 

f *u ™ u't » p 11 • * « to indicate the time when the signature IS generated, and/or 

portion of the message bits as a storage of all prior trans- .i_ ^ u . . , . r Irr 

^ ir *u u J J • / i**r \* 1 another field that represents a random number. In different 

actions of the hardware device (or software program) token. ^ji.. .. , -ij 

The prior transaction bits after they are hashed are sent out P'^^^""^^ embodiments, the agnature package may include 

^ , r ... J * J u *u • • 4 one or more of the above fields, 
as a part of the message bits, and are stored by the recipient 

of the message. Such a process would create an audit trail The invented signature package may be applied to many 
because by unhashing the chain, one can trace back what has different applications. For example, it can be incorporated 
happened. Even if the hardware device token is broken, or interlock protocol to prevent raan-in-the-middle 
the secure software process is reverse-engineered and attack, a digital time^tamping proxy and guaranteed check- 
modified, the attacker cannot change whatever that has been account for spending and reconciliation, 
sent to the recipients in the past. The problem with this Other objects, aspects, and advantages of the present 
approach is that it wastes valuable space that could have invention will become apparent from the following detailed 
been used for the message. description, which, when taken in conjunction with the 
It should be apparent from the foregoing that there is still accompanying drawings, illustrates by way of example the 
a need for an encryption scheme that has a strong audit trail principles of the invention. 

while not wasting a lot of the valuable message space. ^^^^^ DESCRIPTION OF THE DRAWINGS 

SUMMARY OF THE INVENTION p^j. i ^hows a preferred method to digitally sign a 

The present invention provides a strong audit trail for an message in the present invention, 

encryption scheme that does not waste any of the valuable FIG. 2 shows a preferred embodiment of a signature 

message space. The audit trail can be based on the source or packet to be encrypted to form a digital signature in the 

the identity of a device token, such as the ID of the device present invention. 

token, the ID of the public-private key or the encryption 45 piG. 3 shows a few preferred embodiments for the 
scheme. The audit trail can also be based on the sequence of auditing bits in the present invention, 
events or transactions carried out by the device token, which 4 ^j^ows a preferred method in the present invention 
is typically tamper-resistant. In the present invention, a g^^^^^j^ ^ ^^^^^^ signature, which includes a packet- 
device can be a physical device or a software program. sequence number. 

As described in the background section, in order to 50 FIG. 5 shows a preferred method in the present invention 

authenticate a message, it is digitally signed usmg the g^^^^^^^ ^ ^g^^^ signature, which includes a prior 

private key of the sender of the message. The signing signamre 

process is typically done through hashing the message, and ^'^j,^^^ ^ ^^^^^^^^ ^^^^^ ^ 

then encrypting the hashed message by the pnvate key. In , , j- 1 • * u- u • 1 j 

, , -^^^ ^ „ , 7' t ^1 to generate a digital signature, which includes prior mes- 

ordcr to ensure that the encryption becomes extremely 55 & » » 

difficult to break, the hashed message is usually padded to t,^^ « . . , . . . , . 

increase the size of the package to be signed-the signature ^}^- ] ^^^^^^^le application with a log by 

package— to at least 512 bits. Padding schemes are well prefenred methods m the present mvention. 

known in the current art; one is described in RSA Data FIG. 8 shows a spending application based on a guaran- 

Security, Inc/s Pubhc Key Cryptography Standards (PRCS) 60 ^^^d checking account with digital signatures generated by 

documents. The present invention, using the padded space, preferred methods in the present invention. 

puts the auditing bits in the signature package. This FIG. 9 shows a reconciliation application based on a 

approach would not waste message space, and would create guaranteed checking account with digital signatures gener- 

a strong audit trail for the device token. ated by preferred methods in the present invention. 

In one preferred embodiment, the signature packet 65 Same numerals in FIGS. 1-9 are assigned to similar 

includes the message bits, which are formed by hashing a elements in all the figures. Embodiments of the invention are 

message; auditing bits; and redundancy bits for the security discussed below with reference to FIGS. 1-9. However, 
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those skilled in the art will readily appreciate that the size, signature packet format, hash function, symmetric and 

detailed description given herein with respect to these fig- asymmetric encryption. As an example, version 1 might 

ures is for explanatory purposes as the invention extends correspond to signature and asymmetric encryption algo- 

beyond these limited embodiments. rithm RSA with a 768-bit modulus, hash function SHAl, 

DETAILED DESCRIPTION OF THE ^ symmetric encryption function two-key triple-DES, and 

INVENTION without a time stamp and a random number; and version 2 

might correspond to the same types of fields, but with a 64 

FIG. 1 shows a preferred method 200 using a tamper- ^it token-generated random number. A recipient of a signa- 

resistant token to digitally sign a message 204 to form a ture packet with version 2 would then know that, if the 

digital signature 208 in the present invention. The message sender^s tamper-rcsistance had not been defeated, the token 

may be generated by the token, or may be received by the ^as generated a random number in the signature packet, 

token. In the preferred method 200, the message 204. is information on the algorithms RSA, SHAl, and triple-DES 

hashed 202 to form message bits. The message bits with ^^n be found in any modem book on cryptography, 

redundancy bits and auditing bits form a signature packet n • i j- • ^ i . • *i. 

L- , • .J ^ti£^ L • , 1 . / ,u J- V 1 By includmg the signature-packet version, the present 

which IS encrypted 206 by a pnvate key to form the digital ■ \' ^ , t • / i I* i u- u 

mo Vu J- 1 • . -iXo J mvention prevents some kinds of replay attack, which 

signature 208. The digital signature 208 and the message • i . • * ^ * * u • ^ 

-P. J * if w • • * 1 KT * *if * mvolve trying to get a system to use an older signature 

204 are then ready to be sent to a receivine token. Note that i^ • ^7 .i. • - 

rL .1. J . a^v^Aviu^ u , , packet version. Moreover, the signature packet version 

the methods to generate a tamper-resistant token, including T i* •* i • •/ • r *t. • • * i 

jiULL- ..u f 1 becomes explicit, making it easier for the receiving token to 

a tamper-resistant card, should be obvious to those of normal „ .ufL a^^^a^ 

^ J Mi .It.. J ■!_ J ■ scan the version ana then deciae to accept or to refuse to 

skill in the art, and will not be further descnbed m this * •* Tn. • * ^ * -in u i j 

Y accept it. The signature-packet version also allows backward 

* n , , . 1 compatibilityif later versions add more fields or change the 

pe preferred embodiment uses a tamper-resistant token ^-^^j^ sign^Xmc packet, since the signature-packet 

200, but those of ordmary skill in the art will realize that the ^^^^-^^ ^ -^^ 275 can be easily found, ITiis is because the 

token could alternatively be a PC-MCIA card a processor in signature-version bits are typically located at the beginning 

a"button'(similartotheonesold by Dal as Semiconductor, 25 signature packet and with a pre-defined number of 

Inc.), a cryptographic smart-card, an electronic wallet, a ^^^^ as 23 bits 

"dongle" attached to a computer or other processing hard- J. , ,^ , . * • . 

ware device, or a secure microprocessor. Instead of a ^. token ID bite 277 ideatifles the token generatag the 

tamper-resistant token, 200 could be a secure software ^^^"l signatoe. The presence of the token ID 277 simph- 

program executing on a computer, a software program 30 problem of tracmg lost or stolen tokens. In most 

executing on a tampcr-resistant personal computer, a soft- ?^^'}°^} T u ^^^V"^ ^ 

ware program executing on a computer running in a secure ^77, the key ID bits 279 and the packet-sequence number 

. . _ . ^ 281. In one preierred embodiment, the token has a unique 

environment, a software program running on a secure yio u- m 

computer, or a software program running on a computer with ^o-d" t^- 

a secure operating system. FIG. 2 shows a preferred embodi- 35 The key ID bits 279 identifies the private key encrypting 

ment of a signature packet 250, which includes the message signature packet 250. Typically, this key ID is included 

bits 252, the auditing bits 254 and the redundancy bits 256. ^ ^^y certificates and can be fit into an X.509 certificate. 

For the security of the signature, the signature packet 250 (X,509 is a world-wide standard format for certificates.) In 

includes the redundancy bits, which should be a well known one preferred embodiment, the key ID is 48 bits, 

practice to those skilled in the art. The auditing bits 254 40 The packet-sequence number 281 indicates the sequence 

provide an audit trail for the message 204. of signatures generated by the token — a different signature 

FIG. 3 shows a few preferred fields for the auditing bits from the token has a different sequence number 281. FIG. 4 
in the present invention, including signature-packet version shows a preferred method 300 in the present invention to 
bits 275, token ID bits 277, key ID bits 279, a packet- generate a digital signature, which includes the packet- 
sequence number 281, prior signature hash 283 and a 45 sequence number 281. In one preferred embodiment, ini- 
time -stamp 285. One additional field in the auditing bits, tially when the token is just manufactured, it has a packet- 
which may not have significant auditing capability, is a sequence number 281 of a small value, for example, 10. 
random number 287. The auditing bits may include one or From that point on, every time the token generates 302 a new 
more of the preferred fields, for example, the auditing bits signature, the sequence number is incremented 304 by one, 
may include the signature-packet version bits 275 and the 50 the message to be sent is hashed 306, and the token would 
time-stamp 285. Each of these fields except the random encrypt 308 the hashed message with the redundancy bits 
number is useful for preventing or increasing the difficulty and the sequence number to generate the new signature, 
of some kinds of attack. Thus, this packet-sequence number 281 becomes one of the 

The signature-packet version bits 275 indicate to the fields in the auditing bits 254. The packet-sequence number 

receiver of the signature packet 250 the version of the token 55 281 fiiistrates most replay and insertion attacks on protocols, 

generating the signature, so as to inform the receiver how the With the sequence number 281, a "stop transaction" order 

signature packet is to be processed. In one preferred can be issued on all transactions after a certain sequence 

embodiment, the signature-packet version bits 275 is a number to help trace lost or stolen tokens. Additionally, the 

23-bit field that is at the beginning of the signature packet, sequence number ensures that there are never two identical 

with the following structure: 60 signature packets generated by the same properly- 
functioning token. Two packets with the same sequence 
^— ^— ^— number, key ID and token ID is evidence that the token is 

bits 0 ... 7 rcscTvcd-sct to all zeros foi version 1. malfunctioning. In One preferred embodiment, the packet- 

bits 8 . . . 15 version bits-supports up to 255 other versions. sequence number is 32 bits long. 

65 A field that includes the information of hashing the most 

Typically, a given version number conesponds to a num- recently signed signature is another way to create an audit 

ber of features, including digital signature algorithm, key trail for the message created. FIG. 5 shows a preferred 
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method 325 in the present invention to generate such a 
digital signature. The token stores the last signature it 
signed, 327. When the token signs the next signature, the 
token would hash 329 the prior signature, hash 331 the 
message related to the next signature, and the token would 
encrypt 333 the hashed message with the redundancy bits 
and the prior signature to generate the next signature. This 
ensures a complete chain of past signatures by tracing every 
signature to get its prior signature. With such an 
implementation, defeating the tamper resistance of the token 
would not allow an attacker to alter previously completed 
transactions with signatures. This creates an audit trail that 
is almost as difficult to bypass as it is to find collision values 
for the hash function. 

Similarly, in another preferred embodiment of the 
invention, the hash of the most recent message is also 
included in the current message. In this preferred 
embodiment, the token stores the chain of messages it has 
signed, with each message hashed. When the token signs the 
next signature, the token would append the message related 
to the next signature to the chain of hashes in the token, hash 
the appended chain, hash the message, and encrypt 356 the 
hashed chain with the redundancy bits and the hashed 
message to form the next signature. At this point, the 
appended chain becomes the chain of messages. Another 
variation of the above method 350 is shown in FIG. 6. In that 
example, a document is sent 351 to the token 100, which 
would append 352 the document to a chain of hashes 
previously stored in the token to form a data set. The chain 
of hashes represent the hashes of the previous messages 
signed by the token 100. The token then hashes 354 the data 
set. Finally, the token encrypts 356 with its private key the 
hashed data set, redundancy bits and the received message, 
as in the method described in FIG. 1, with the hashed data 
set as the auditing bits. With every protocol message cryp- 
tographies Uy dependent upon every previous protocol 
message, an auditable chain is created that extends through 
every transaction performed by the token 100. Again, this is 
intended to make recovery from various kinds of attack as 
easy as possible, and to leave a very strong audit trail; and 
as a side-effect, the chain of hashes produced frustrates 
insertion and replay attacks in any protocol where the 
chained hashes are checked, and all messages in the protocol 
are signed. 

In one preferred embodiment, the internally generated 
time stamp, 285, and the random number, 287, are included 
as two separate fields in the signature-packet 250. Each may 
occupy 64 or 128 bits. Both values provide the guarantee 
that if the token's tamper-resistance has not been defeated, 
these values come directly from the token 100, 

Note that the auditing bits may include more than one of 
the fields described above. A user may pick and choose 
whichever field or fields the user wants to be included in the 
packet. In fact, the auditing bits may include all the different 
fields shown in FIG. 3. 

The signature packet's minimum size is determined by the 
size of the hash function's output, and the number of fields 
discussed above that have been included. The table below 
shows the number of bits required in applications such as 
RSA, for the signature packet of various hash function 
output sizes. 
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Hash Size 


Packet Size 


160 


471 


224 


599 


256 


663 


288 


727 



These packet sizes determine the smallest modulus size 
"'^ useable in RSA with the signature packet format. For 
example, using a 160-bit hash function such as SHA I, one 
preferably needs a modulus of more than 472 bits. 
Preferably, the modulus has one more bit than the packet 
size, so that all valid signature packets is encoded. Using a 
288-bit hash function, such as the concatenation of MD5 and 
SHAl, one preferably needs a 728-bit modulus. 

Another requirement for the packet size is that it should 
be large enough so that after encryption, the result is almost 
impossible to de -encrypt without the available key. A task is 
considered impossible if it takes tremendous amount of 
computing time, for example, on the order of approximately 
1030 operations with conventional computational methods 
and equipment, and with such de-encryption characterized 
by the class of mathematical functions known as one-way 
cipher functions. This implies that the packet size should 
preferably be more than 400 bits. 

The invented signature packet formats described above 
can be applied to generate protocol building blocks, such as 
30 for interlocking and transmitting tmsted values from the 
token 100. The building blocks simplify the design of robust 
and secure protocols. 
Interlock 

An interlock protocol is intended to convince two tamper- 
35 resistant user tokens that they are communicating with one 
another in real time and to prevent man-in-the middle attack. 
Such an interlock typically requires signatures. When there 
is a need for a signature, one of the above invented signa- 
tures is used. After the interlock protocol is performed, if all 
40 messages are signed with one of the above signature packet 
formats, then insertion, alteration, or replay of messages 
should be very difficult. 

There are numerous algorithms for an interlock protocol. 
The following serves as one example of such an interlock. 
45 Note that the symbol certificate(x) denotes the certificate of 
x, which will not be further described because this function 
should be wcU known to those skilled in the art; and the 
symbol sign(x) denotes signing the message x with one of 
the preferred methods as described above. (1) user A: 

a. Generates a random number, RO. 

b. Forms message MO>=(RO, Certiflcate(user A)). 

c. Sends to user B MO, Sign(MO). 

(2) user B 

55 d. Verifies Certificate(user A). 

e. Verifies Sign(MO). 

f. Generates a random number, Rl. 

g. Forms Ml=hash(MO), Rl, Certificate(user B). 
60 h. Sends to user A Ml, Sign(Ml). 

(3) user A 

i. Verifies Certificate(user B). 
j. Verifies Sign(Ml). 
k. Verifies hash(MO). 

1. Forms M2-(hash(Ml), first_protocoL_message). 
m. Sends to iiser B M2, Sign(M2). 
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(4) user B 

n. Verifies Sign(M2). 

0. Verifies hash(Ml). 

At the end of step (3), user A has seen enough to verify 
that she is getting a response by someone who knows user 
B's private key, as specified in Certificate(user B), because 
he has returned a signed message, which includes a hash of 
her first (partially random) message, and a key certificate. 
After step (4), user B can verify that he's getting a response 
from someone who knows user A^s private key, as specified 
in Certificate(user A), because he, too has gotten an appro- 
priate response from his message. In both cases, they know 
that the other party has received their entire certificates 
intact, as well 

In the above example, verifying the certificates preferably 
denotes verifying the signatures, the valid dates (possibly 
the issued-datc of the other party's certificate against the 
issued-date of the token's own certificate), and possibly 
checking the certificates against a list of known stolen or 
invahd key IDs or token IDs. Such verifying processes 
should be known to those skilled in the art. 

While user A, the token, knows whom she's dealing with 
(user B, whose token ID and key ID are preferably noted 
inside Certificate(user B)), it is diEBcult to ensure that user 
A's human owner knows which user B she's iateracting 
with. For applications in which this is a problem, it is a good 
idea to equip each token with some kind of display, and to 
show some human-readable identification from Certificate 
(user B). This gives the owner of user A, the token, an 
opportunity to end a transaction in which she does not want 
to be involved, or at least the knowledge that she has been 
involved in this unwanted transaction. The technique to put 
a display on a token is well known in the art, and will not 
be further described in this application. 
Interlock With Privacy 

The above interlock protocol can be extended to an 
interlock with privacy with two tokens, each having its own 
set of public and private keys, and with the interlock 
supporting a secure key exchange, and encrypted commu- 
nications. Again, when there is a need for digital signature, 
one of the above invented signatures is used. There are many 
interlock-with-privacy schemes. The following shows one 
example of such an interlock-with-privacy, with siinilar 
symbols as the above example being of similar meanings. 
Note that PK(x) denotes x's public key, and PK_Encrypt(x, 
key=PK(y)) denotes encrypting x with y's pubUc key. 

(1) user A 

a. Generates a random number, RO. 

b. Forms message M0=(RO, Certificate(user A)). 

c. Sends to user B MO, Sign(MO). 

(2) user B 

d. Verifies Certificate(user A). 

e. Verifies Sign(MO). 

f. Generates a random number, Rl. 

g. Forms Ml=hash(MO), Rl, C6rtificate(user B). 

h. Sends to user A Ml, Sign(Ml). 

(3) user A 

1. Verifies Cerlificate(user B). 
j. Verifies Sign(Ml). 
k. Verifies hash(MO). 
1. Generates a random number, R2. 
m. Forms KE=(PK_Encrypt(R2, keyoPK(user B)), 

Pie_Encrypt(R2, key=PK(user A))), 
n. Forms M2-(hash(Ml),KE). 
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o. Sends to user B M2, Sign(M2). 
p. Forms session key KS=hash(R0,Rl,R2). 
(4) user B 

q. Verifies Sign(M2). 
r. Verifies hash(Ml). 

s. Forms session key KS=hash(R0,Rl,R2). 

In the above example, R2 is encrypted under both user B 
and user A's public keys, so that either token can reproduce 
R2 to generate the session key KS. After step s, user A and 
user B sign the plaintext messages, then encrypt them and 
their signature packets under a symmetric algorithm using 
the session key KS. The specific symmetric algorithm 
should be specified by the signature packet version. In some 
systems, R2 is also encrypted under an auditor's public key 
so that the auditor can reproduce the session key KS. 
Signature Package with Additional Information 

Some protocols benefit from having the token generate 
some internal, trusted value, such as random numbers or 
time stamps. One example is based on the interlock example 
above, with the purpose of the interlock operation to be for 
user A to get such a trusted value from user B. User A's 
first_protocol_message is set to a request for a random 
number or a time-stamp. User B, after step o, responds by an 
acknowledgment message, signed with a signature packet, 
which applies one of the above invented signatures that 
includes a random value or a time stamp in the packet. The 
packet preferably should include the signature packet 
version, which indicates that this packet's random number 
or time-stamp emerges from the signature packet generated 
by the token 100. Another example is based on the interlock 
with privacy example above, which is for applications with 
these trusted values being private. After step s, the next 
message requests a random number or time-stamped signa- 
ture packet, which is encrypted with the session key. The 
recipient of that message would respond with a random 
number or a time-stamp in the signature package, which is 
encrypted by the session key. 

Digital Time-stamping Proxy Based on a Master Server 

In one preferred embodiment, the present invention is 
applied in the area of a master digital time -stamp server. The 
tamper-resistant token card may sit on a network, and 
includes in its signature package a time-stamp. The card is 
available for users of the network to time -stamp their 
documents. As described in one of the above appHcations, 
the card retains a chain of hashes, which is formed from all 
the signatures it has signed. When a user sends his document 
to the token, the token would sign and time-stamp the 
document. Then, the document is appended to the chain of 
hashes to form a data set, which is hashed to form the new 
chain of hashes. The sequence of the chain follows the 
chronological order of the signatures signed. Perhaps once 
per week, the card sends its chain of hashes to a master 
time-stamp server to be time-stamped. The master server 
time-stamps the chain, sends it back to the card, but also 
retains the hash of the chain of hashes. Since the chain is 
stored in the server, the chain cannot be altered even if the 
tamper resistance of the card is defeated. 

Again three tokens are used as an example for the above 
described operations: user A, the tamper-resistant token 
card, providing time-stamping service in its signature, as 
described above, and the master time-stamp server. 

When user A has a hash value to get time-stamped, she 
interlocks with the token card, and sends her hash value as 
her first protocol message. In one preferred embodiment, 
after user A and the token card have completed steps (1) 
through (4) in the interlock protocol described above, the 
token card performs the following: 
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p. Forms M3=hash(M2). 

q. Sends to user A M3, Sign__with_time-stamp(M3). 
At this point, user A has a verification of her hash, time- 
stamped by the token card. 

At a preset interval, such as a week, the token card 
interacts with the master server First the token card and the 
master server interlock. Then, the token card sends its chain 
of hashes to the master server to be time-stamped. The token 
card ends up with a time-stamped verification of his chain. 
The master server retains the chain of hashes as a master 
proxy. In one preferred embodiment, the card token reini- 
tializes its chain so that the next hash from user A will be the 
beginning of a new chain. These hashed chains in the master 
server could even be backed up of[-site or off the network on 
a regular basis. 

If the token card is stolen or broken into, the users who 
have interacted with the token card could get together to 
recreate their interactions with the token card, and could 
(with the master server's help) produce authentication of the 
order of their time-stamps since the token card's last inter- 
action with the master server. Every interaction before that 
has been saved by the master server, and can be authenti- 
cated. 

— Auditable Applications Based on a Log 

One way to establish a strong audit trail is to establish a 
log for every operation, and to make it very dif&cult to delete 
or alter the log without being detected. FIG. 7 shows an 
auditable application that establishes a log for every opera- 
tion by preferred methods in the present invention. 

As an example of the protocol, there are four players: the 
user token, the application token, the audit token, and the 
attacker. The user token first interlocks 402 with the appli- 
cation token, and then sends 404 the application token a 
request for some operation or information. The request 
process 404 is preferably achieved by signing 406 the 
request with one of the preferred methods in the present 
invention, and then sending 408 the signed request with the 
request to the application token. If the user token is autho- 
rized for such an operation — the application token knows 
the user token's identity after the interlock protocol — then 
the application token would perform the operation. In any 
case, the application token keeps the request in a log. 

The audit token regularly interacts with the application 
token. First, they interlock 403, and then the audit token 
requests a copy of the log since their last interaction. The 
application token verifies that audit token is authorized for 
this, and if she is, sends 410 her the log, preferably encrypted 
and signed. The audit token can use the log to verify all 
transactions that have occurred in the time covered by the 
log. Note that the audit token may repeat 414 the process of 
asking for the log regularly because presumably the log 
should keep on changing as there should be more requests by 
the user token to the application token as time goes by. 

In more detail, whenever a signed request is received by 
the application token, the request would be appended 412 to 
a chain of all the prior requests, and then with the entire 
chain hashed to form the new chain. When the application 
token sends 410 the log to the audit token, the application 
token typically digitally signs 414 the log and then sends 416 
the log with its signature to the audit token. Note that the 
repeat process 418 may repeat from the point of signing 414 
the log. Also, the interlock can also be an interlock- with- 
privacy. Additionally, as shown in the example on interlock- 
with-privacy, 

the application token may also encrypt R2 with the audit 
token's public key in step m, so that the audit token can also 
generate the session key. 
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With the above operations, the attacker after defeating the 
tamper-resistance of the user token still cannot change the 
log kept by the application token. Even if the attacker further 
defeats the tamper-resistance of the application token, any 
alterations the attacker makes will be detected by the audit 
token when she interlocks with the application token 
because she should be able to notice inconsistency in the log. 
The attacker can delete the log in the appUcation token, but 
only for the short period of time between the audit token's 
interactions with the application token. In addition, if 
attacker wants to reverse engineer the application token, he 
has to somehow convincingly interact with audit token and 
one or more user tokens while doing it. Otherwise, the audit 
token and the user token will become aware of the applica- 
tion token being tampered. 
The Guaranteed Checking Account 

There are many payment protocols available these days. 
The following are examples demonstrating the ease of 
building good payment protocols with the invented signa- 
ture packets. 

One preferred embodiment allows a tamper-resistant user 
token to have a guaranteed checking account with sufBcient 
funds to cover each "check" guaranteed by the card. It is 
important that the account the card draws on must be frozen 
while the card is interacting with another token to ensure that 
there is sufficient fund to be spent. The preferred embodi- 
ment creates an audit trail for the user's transactions. 

In the preferred embodiment, any two user tamper- 
resistant tokens, such as xiser A and user B, can ttansfer 
money freely between them. Similar to checking accounts, 
if user A has $500 and user B has $200, it is possible for 
them to interact to distribute that $700 in any way they 
choose. However, the preferred embodiment preferably pre- 
vents them to interact in such a way that their total money 
becomes more or less than $700. Also, in the preferred 
embodiment, user A can reconcile its account with a bank 
token. If there is an intruder attacking user A's account, an 
audit token and the bank token may be able to recover from 
it. 

User A and User B Interact 

FIG. 8 shows one set of preferred steps 450 for user A to 
interact with user B, such as when user B asks user A for a 
transfer of funds. To start the process, user A and user B each 
obtain 452, 454, a certificate from the bank token, which acts 
as a certifying token. The bank account digitally signs the 
certificates with one of preferred methods described above 
that includes time-stamps in the signature package. The 
time-stamp indicates the issue date of a certificate. 

After getting their certificates, user A and user B interlock 
456, and exchange their certificates. If the issue dates of the 
two tokens' certificates are more than a preset amount of 
time apart, such as a week, then the tokens refuse to accept 
the certificates as valid, and the interlock protocol fails, 458. 
This precaution is to limit the total amount of time that a 
rogue card — one which has been reverse-engineered — can 
possibly write bad "checks." The smaller the preset amount 
of time, the more often tokens have to interact with the bank 
token, but also the less time a rogue token has to write bad 
checks. If the issue dates of the two tokens' certificates are 
within the preset amount of time apart, user A would send 
460 user B an encrypted and signed "check." In one pre- 
ferred embodiment, the check is signed by one preferred 
method as described in the present invention. The check 
should indicate user A's account number, and the amount of 
money to be transferred. In one preferred embodiment, their 
account numbers are the hashes of their public keys, which 
preferably have been exchanged with the certificates in the 
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interlock protocol. At this point, the protocol ends with an party that can decide whether to perform them. The bank 

acknowledgment message 462 from user B. In one preferred token then transmits 512 user A her current verified balance, 

embodiment, the acknowledgment message is signed by In one preferred embodiment, tlic bank token may scad user 

user B through one of the preferred methods in the present A her new certificate in the same message. User A verifies 
invention. After the transactions, both user A and B adjust S and reconciles the current account with her log, and may 

their internal balances, and go on about their business. If ^end the bank token a receipt. The bank token may sign the 

user A does not receive the acknowledgment message, she ^^^^^1?^ sends it back to user A. If she does not get this 

flags it as an error condition and assumes that the money has ^^^^ ^^^^ ^ack and mteract wiO) the bank token 

been transferred to user B. This should be relatively rare, but fS^" « d^ai this issue. K user A has had some 

. , V , , / 44 I transactions without proper receipts, she can note this m her 
It needs to be defined to prevent sonie classes of attacks. lO ^^^^^^^^^ ^ and the bank token should reconcile this as 

In another preferred embodiment, user A and user B well as possible. If the bank token has not yet heard from the 

mtcrlock with privacy, for example with the method as ^^^^^ ^ ^^^^^ transactions without receipts, the bank 

described above. Then, preferably, R2 should be encrypted ^^^^^ ^^y readjust user A's account, 

in step m by the bank token's pubUc key so that the bank ^ ^ ^ank token learns of overdrawn checks or 
token can also generate the session key to access the 15 stolen or lost tokens, the bank token adds those defective 

transactions. tokens' certificates, preferably with their key and token ID, 

Reconciling with the Bank to the bad certificate list, and refuses to issue those tokens 

The purpose of reconciliation is for user A to send her another certificate until problems have been resolved, 

accumulated logs of transactions to the bank token for Audit 

verification, and then for the bank token to send her the 20 In one preferred embodiment, the bank token routinely 

verified account for her to reconcile with her log. Typically, interacts with the audit token, such as once a day. The bank 

the bank would also send her a new certificate, and a new list token and the audit token interlock- with-privacy. Then the 

of invalid keys or certificates that she should not interact bank token sends the audit token die logs that have come in 

Y^iltj since their last interaction, and gets back a time-stamped 

The preset time for a user to renew his certificate defines 25 receipt. Again, the logs can be in the form of chain of hashes 

how often each user must reconcile with the bank, because described above. With the logs from the bank token in the 

the bank issues certificates. If the preset amount of time is ^""^^ ^^^'^ }^ ^^^^^^ ^ 

20 days, then each token must reconcile with the bank every previous logs cannot be changed, and 

J u - * 1 u ui TP *u * it should be possible to verify that the logs are correct up to 

20 days, or his token becomes moperable. If the preset ■ * f u i • *u * - * 

\ c • c i .X. *u • t u * the point of breaking the tamper-resistance, 

amount of time is 5 days, then there is only a very short 30 , , „ , * 

■ J ir u I J » 1 * ■ * u J u 1 Distributed Tokens 

window for a user with a hacked loken to wnte bad checks, ^^^.^ ^^^^ performed by a 

before his token is permanently frozen. The bank token may ^^^^^^^ ^^^^^^ ^ j ^^^^^^ ^^^j, 

even discount a high-volume user, who operates with a ^^^^^ time-stamping proxies or tokens. Each is 

lower preset amount of time, perhaps rcconcilmg once per i„pi,,^enled in tamper-resistant hardware, with, for 

^^1 ^ 1 ■ . .L L 1 . L.I example, a tamper-resistant clock. The audit tokens continu- 

If user A complams to the bank that someone has stolen ^„^u, ■ „ . „^ ^„„„, ^„ „ft„„ tu^ «„^:t t«v«« 

. . , - , . ,.j ously interact, such as every so often, the first audit token 

her token, the bank would not re-issue a valid certificate to u^^i/. i ^ ^^♦^ « f^^«, tu^ 

/, . 1 1 J 1 i_ r J r backs up its logs and gets a time-stamp trom the second 

the user token, so the robber could only have a ew days of ^^^^ ^^^^^ ^^^^ ^ preferably by one of the 

spending left. Addilionally, ttie token ID and the key ID ^^^^^^ ^^^^^^ ^ the present invention, for example, 

should preferably be put on the reiect-ust, which the bank j. . . 41. i j j- *u 1 ■* 

^ . ./ ^ . T. digitally signma the logs and sending the log with its 

token sends with every certificate it issues. It would become j o u a - c 

j-rc 1. f .L . . 1 . 1 r *u signature to the second audit token. Such a design further 

very difficult for the robber to use the stolen token, or for the . * •* ^ * 

• 1 J » 1 r» -I- mcreases the security 01 the system. 

user of a hacked token to write bad checks. Reconciliation ^ • * u 1 j 1 • 4 j *t, * • 

. „ . .., . 1 . 1 . 1 > From the foregoing It should be appreciated that a signa- 

should be possible by telephone so long as the token s ^ .^^^^^^ ^^j^^^^ ^^^.^ ^^^^ 

certificate has not lapsed. If it has lapsed, then the token 45 . ^ _ ™ . . . ^ « ^■^A * „ 

,f . . «- mformation. This signature package can be applied to many 

should need to be brought into a branch office of the . . 1 . iu % f fu * 1 

... , r . r ' 1 ■ different protocol to increase the security of those protocol, 

bank — this gives the bank some chance of noticmg physi- -^u * *• *t. * 1^ u \i p ^ 

, , f . , , , , . . ..t . / without wasting space that could be used for messages, 

cally hacked tokens, and also leaves the bank with pictures u ? • . • -n u * # 

' J, „ 1 ' f J Other embodiments 01 the invention wul be apparent to 

on its secunty cameras 01 some or the people mvoived. ^, 1 n j • *u _* ^ • j f *u- 

^„ ^ , ..... _, those skilled in the art from a consideration of this specm- 

FTG. 9 shows a reconciliation application 500 based on a 50 ^. ^. r ■ j- 1 j u • t* - 

, J , , . . • r J XL J • XL cation or practice of the invention disclosed herem. It is 

guaranteed cbecki^ account usmg preferred methods m the ^^^^^ specification and examples be considered 

present mvenuoa First, user A and the bank token interlock ^^^ ^ ^.^^ .^^ 

502, which can be an mterlock-with-pnvacy. Next, user A i^J„„ :„J,v„t^^ u„ tu^ f^ii™;„„ ^u;^. 

, .-c . c u f * 1 A> mvention bemg indicated by the following claims, 

obtains 504 a certificate from the bank token. The user A s claim* 

certificate should be constantly renewed within a preset 55 ^ . . ' ^ ^ • , u- n a 

. J f.. T, . y cf\c u 4 r 1 1. A method for performing a cryptographically assured 

period of time. Then, user A signs 506 her transaction log 1 * • . ^ ^ u jJ 1 a 

^, u 1 . M- ** f A cAo *u 1 %u u electronic transaction requested by a user module, and 

smce her ast reconci liauon, and sends 508 the log with her ^^ independent audit trails therefor, com- 

signature to the bank token. The sigmng process is based on ^^^j^ ^ steps performed by an application module of: 

one of the preferred signmg process in the present invention. . ■ . 1^1 
The transaction log includes all the transaction the user 60 ^) cryptographically intcrlockmg with a user module; 

token has been involved. The bank token, based on the W receivmg, from said user module, a cryptographically 

user's account the bank has, verifies 510 that her transac verifiable transaction request; 

tions do not disagree with other inforaiation available to the (c) cryptographically verifying said received traasaction 

bank token, and that the log is internally consistent. User A request; 

may also request some additional transactions, such as 65 (d) electronically perfonning said transaction; 

moving money into or out of her account. The bank token (e) logging said performed transaction as part of a digi- 

raay perform, refuse, or forward the requests to some other tally signed hash chain including at least one previously 
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performed transactioQ, to provide a first cryptographi- 
cally assured audit trail of said transaction; 

(f) cryptographically interlocking with an auditing mod- 
ule separate from said application module; and 

(g) transmitting said hash chain to said auditing module, 
to provide thereat a second cryptographically assured 
audit trail of said transaction, independent of said first 
audit trail in said application module. 

2. The method of claim 1 where said transaction request 
is for a digital timestamp of a user message. 

3. The method of claim 2 where said second cryptographi- 
cally assured audit trail includes a digital timestamp of the 
receipt, at said auditing module, of said first cryptographi- 
cally assured audit trail. 

4. The method of claim 1 where said application module 
is a time stamping module, and where said auditing module 
is a master time stamping module. 

5. The method of claim 1 where said receiving step (b) 
occurs after each receipt of a transaction request from said 
user, and where said transmitting step (g) occurs after 
receiving a plurality of transaction requests from users of 
said application module. 

6. The method of claim 1 where said application module 
is a bank module, and where said transaction is an electronic 
payment order from a guaranteed checking account of said 
user to an electronic payee module, 

7. The method of claim 6 further comprising the step, after 
said step (a), of cryptographically interlocking with said 
electronic payee module, and wherein said user module 
sends said payee module an electronic check if a temporal 
interval between (i) said user module's interlock with said 
bank module, and (ii) said payee module's interlock with 
said bank module, is less than a predetermined hmit. 

8. The method of claim 7 where each said step of 
interlocking includes transmitting a signed certificate from 
said bank module to said module interlocking therewith. 

9. The method of claim 8 where said signed certificate 
includes a timestamp from said bank module. 

10. The method of claim 7 where said electronic check 
includes an account number of said user and an amount of 
money to be transferred to said payee. 

11. The method of claim 6 further comprising the step of 
electronically reconcihng account balance records held by 
said user module and said bank module. 

12. The method of claim 11 where said reconciling step 
includes: 

(i) receiving, from said user module, a log of transactions 
conducted thereby; 

(ii) cryptographically verifying that said received log is 
proper; 

(iii) transmitting, to said user module, a verified balance 
of said user's account balance. 
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13. The method of claim 12 where said step of verifying 
said log includes checking that said log does not disagree 
with information available to said bank module. 

14. The method of claim 12 where said step of verifying 
S said log includes checking that said log is internally con- 
sistent. 

15. The method of claim 1 where at least one of said 
modules is a tamper-resistant hardware token. 

16. The method of claim 1 where at least one of said 
modules is a secure software application. 

17. A cryptographic application module for performing a 
cryptographically assured electronic transaction requested 
by a user module, and providing multiple independent audit 
trails therefor, comprising: 

(a) means for cryptographically interlocking with a user 
module; 

(b) means for receiving, from said user module, a cryp- 
tographically verifiable transaction request; 

20 

(c) means for cryptographically verifying said received 
transaction request; 

(d) means for electronically performing said transaction; 

(e) means for logging said performed transaction as part 
25 of a digitally signed hash chain including at least one 

previously performed transaction, to provide a first 
cryptographically assured audit trail of said transaction; 

(f) means for cryptographically interlocking with an 
auditing module separate from said application mod- 
ule; and 

(g) means for transmitting said hash chain to said auditing 
module, to provide thereat a second cryptographically 
assured audit trail of said transaction, independent of 

35 said first-audit trail in said application module. 

18. The application module of claim 17 configured as a 
bank module, wherein said transaction is an electronic 
payment order from a guaranteed checking account of said 
user to an electronic payment module. 

19. The application module of claim 18 further compris- 
ing means for reconciling account balance records held by 
said user module and said bank module. 

20. The application module of claim 19 wherein said 
means for reconciling includes: 

(i) means for receiving, from said user module, a log of 
transactions conducted thereby; 

(ii) means for cryptographically verifying that said 
received log is proper; and 

50 (iii) means for transmitting, to said user module, a verified 
balance of said user's account balance. 

* i¥ * * 
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